8bitfiles.net/archives/archives.tar/archives/compuserve-file-archive/22 Graphics & Utilities/GIF01.THD

Text File | 2019-04-13 | 5.8 KB | 128 lines

#: 22725 S10/Graphics Util & GIF
    18-Apr-90  13:17:56
Sb: #array .GIF?
Fm: John Ritter 76334,1433
To: [F] Todd Heimarck/Sysop 76703,3051 (X)

OK... so here I am in the message board. What I was thinking is using 4096
bytes as my string table. The first 'n' are for the initial color table, byte
'n' is the clear code, byte 'n+1' is the EOI, and then the rest are free for
the decompression, as follows: The first character received goes in a temp
byte: <old>, and is placed in temp storage. The next character received either
will or won't be in the code table. If not, then <old> replaces it, and the
output code is:   <old> + the byte values of the memory array (the 4096 bytes)
up to the current limit of the string table. Then you get the next code,
compare it, etc. If it does appear in the string table, then make your pointer
equal to that value (say 'n + m') then output the string byte by byte from
<old> + <n+2> to <n+m>.
     I may be missing something crucial there, but it seems fairly straight
forward. Now the next bit is creating the bit patterns for the codestream
(grabbing the GIF encoded data) from a stream that may be 4 bits long up to 12
bits/character, all on an 8-bit machine.




#: 22736 S10/Graphics Util & GIF
    20-Apr-90  04:01:44
Sb: #22725-array .GIF?
Fm: Todd Heimarck/Sysop 76703,3051
To: John Ritter 76334,1433 (X)

John:
   It _is_ pretty straightforward and the actual coding shouldn't be tough,
except in two areas (both of which are inherent limitations of the 64).  The
first is memory.
   Let's say your 16 colors are called "a" through "p".  And let's say code 500
represents the string of pixels "abcacac."  How do you represent that in
memory?  Do you use up seven bytes?  No.  Consider this: there are potentially
4096 codes and in the worst possible case, code 18 has two colors, 19 has 3, 20
has 4, and so on, up to code 4095 has 4079 pixels.  If you add that up, you'd
need approximately 8 million bytes of memory to hold the possibilities.
   But I've figured out a tree that uses only five bytes per code (5 * 4096 is
only about 20K, which fits easily into a 64 or 128).  You need one byte for the
color, two bytes for a pointer to the oldest child, and two bytes for a pointer
to the next sibling.  (This is for encoding, BTW, where you need to build the
table).  For decoding, you need one byte for the color, and two bytes for a
pointer back to the immediate parent.  I'd also add two bytes for a temporary
pointer forward.
   So when you get code 500, you check #500 and its color is "c" (the last byte
in "abcacac").  Its parent node is, say #480, so you move back and get the
color "a" (second-to-the-last-byte) and insert the temporary pointer (at 480)
to point to 500.  Then you work backwards until you have one of the original
colors (number 0-15), which is "a".  Then you follow the breadcrumbs back to
where you started and output a, b, c, etc. to the screen.  Then you have to do
two things: take the first byte (the first "a"), which has to be the final
color of the most recent string (maybe #779, which doesn't know its color byte
yet).  Then you add the next code (#780, which links back to code #500, its
parent, but 780 doesn't know its color yet).
   <<continued in next message>>






#: 22737 S10/Graphics Util & GIF
    20-Apr-90  04:02:02
Sb: #22725-array .GIF?
Fm: Todd Heimarck/Sysop 76703,3051
To: John Ritter 76334,1433 (X)

<<continued>>
   The second problem is deciding which colors are displayed.  I assume you're
writing a decoder for the 64's hi-res screen (but the problems are similar on
the 128's 80-column screen).
   Let's say you're decoding a 256-color picture that originated on an IBM with
a VGA screen.  You get the RGB values up front, and at that time you should
translate each IBM color into one of the 16 available colors on the 64, which
is no problem (I can go into more detail if you want).  That way, when you get
color 251, maybe it translates into the 64's cyan (or whatever).
   Here's the problem: On the 64's hi-res screen, each 8x8 section can only
contain two colors -- a foreground and a background.  But in the IBM picture,
there might be 64 different colors.  How do you decide which two colors to
display?  One solution is to let them vote.  Whichever colors are most popular
are the ones you use.  That works on regular (non-interleaved) pictures, but
you may run out of memory with interleaved pictures, which provide line 0, line
8, line 16, etc., then go back and fill in the blanks.
   So, good luck, John.  If you're confused about any of the GIF details, give
me a holler.
   ToddH







#: 22751 S10/Graphics Util & GIF
    21-Apr-90  08:54:45
Sb: GIF again
Fm: John Ritter 76334,1433
To: [F] Todd Heimarck 76703,3051

I know about the color 8x8 matrices and it seems like GIFFY.BIN uses an update
algorythym (sp?) that merely changes the colors dependant on what colors are
present. It seems that the first color from the first value of the code table
(the first root) is assigned as a 'background color' and then all the others
fight it out: the last color updated in the particular matrix becomes the final
color of that matrix. The only problem I can see with this on the 80 col screen
is that without the 128D conversion, you're limited tmonochrome if you want
bit-map. Of course, it doesn't mean black/white, but say the third color = red.
Sometimes that will be light (as in a black background) or dark (as in a cyan
background). With all the finely tuned images presented in a digitized picture,
which is bit-mapped images strong point, the question becomes 'How do we
differentiate between light/dark'. But even this is e
.. Just look at all the greyscales being done. I've already worked through a
matrix for color assignments based upon RGBI, so that should prove to be no
hassle. Skol! and I'll be back on later to let you know what's up!